30 天系列最後一篇，也是到了說再見的時候了
起初跟著阿柴從 SOLID 五原則，一路走過創建型五個、結構型七個、行為型八個
柴咖啡從小店面開到串外送平台、開到連鎖店規模
能走到這裡，對我來說也是蠻不容易的，對於所說的原則，每篇都讓我消耗大量的腦力
既然是最後一天了，那我們來複習這幾天的旅程吧
| Day | 原則 | 主要解決的問題 |
|---|---|---|
| 3 | SRP | 一個類別／方法扛了太多互不相關的職責，任一職責的變動理由都會牽動、甚至弄壞其他職責的程式碼 |
| 4 | OCP | 每新增一種變化，都得回頭修改既有、穩定的程式碼，而不是靠擴充來因應 |
| 5 | LSP | 子類別的行為跟父類別的約定不一致，呼叫端被迫額外判斷，破壞了多型的可替換性 |
| 6 | ISP | 介面塞了太多不相關的方法，實作者被迫依賴、實作根本用不到的東西 |
| 7 | DIP | 高層邏輯直接依賴具體實作的細節，導致要抽換實作（例如換成測試用假物件）變得很困難 |
| 8 | SOLID 取捨 | SOLID 的使用時機，以及原則彼此打架、跟 KISS/YAGNI/DRY 之間如何拿捏 |
| Day | Pattern | 主要解決的問題 |
|---|---|---|
| 9 | Factory Method | 建立物件的邏輯散落在呼叫端，新增一種產品就要回頭修改既有的判斷式 |
| 10 | Abstract Factory | 需要一次產生一整組彼此搭配的相關物件，但各自建立容易配對出不相容的組合 |
| 11 | Builder | 建構一個物件需要大量可選、可任意組合的參數，建構子的參數列不斷膨脹、難以維護 |
| 12 | Singleton | 某項資源全域只該存在一份，卻缺乏管控，導致各處各自建立、彼此衝突 |
| 13 | Prototype | 建立新物件的成本很高（初始化複雜、欄位很多），而新物件其實只有小幅調整 |
| Day | Pattern | 主要解決的問題 |
|---|---|---|
| 15 | Decorator | 需要在不修改原始物件的前提下，動態疊加、任意組合額外的職責 |
| 16 | Adapter | 既有介面跟需要串接的介面不相容，又不能去改動任一方的原始程式碼 |
| 17 | Facade | 一個流程要依序呼叫多個子系統，呼叫端被迫認識所有子系統的細節與呼叫順序 |
| 18 | Proxy | 需要在不動原始物件的情況下，在存取前後加上控制（快取、權限驗證、延遲載入等） |
| 19 | Composite | 物件之間存在「整體與部分」的樹狀結構，呼叫端卻得為「單一物件」和「一群物件」寫不同的處理邏輯 |
| 20 | Bridge | 抽象與實作是兩個各自獨立變化的維度，卻被綁在同一個繼承階層裡，任一邊增加選項都造成類別數量爆增 |
| 21 | Flyweight | 大量物件之間有大部分內容重複，各自持有一份導致記憶體浪費 |
| Day | Pattern | 主要解決的問題 |
|---|---|---|
| 22 | Strategy | 同一件事有多種做法，卻用大量條件判斷寫死在同一個方法裡，新增做法就要改既有程式碼 |
| 23 | Observer | 一個狀態改變，需要通知數量不固定、事後才會決定的多個對象，而發送方不該知道接收方是誰 |
| 24 | Command | 需要把「操作」本身當成物件處理，才能支援排隊、記錄、撤銷、重做這類延後執行的需求 |
| 25 | Template Method | 一套流程有共同的骨架，只有其中幾個步驟會因情況而異 |
| 26 | State | 物件的行為隨內部狀態改變，狀態判斷式散落各處，新增一種狀態就要到處補判斷 |
| 27 | Chain of Responsibility | 一個請求可能要依序被多個處理者判斷、處理，但送出請求的一方不該預先知道該由誰處理 |
| 28 | Mediator | 多個物件之間互相直接呼叫、互相依賴，任何一個物件的變動都牽連一整片 |
| 29 | Iterator | 需要走訪集合內容，但不想讓呼叫端認識集合底層的資料結構 |
走到現在，應該有敏銳的朋友發現，總共有23 個 Pattern 怎麼只有講 20個?
剩下 Memento、Visitor、Interpreter
因為篇幅不夠了xd 之後可能(?)會更新在自己的網站上，如果這一路來我的文章有幫助到您，也歡迎來看看
而最後的最後，我想來覆盤一下，而第一件事，就是列表自己想要探討的問題，並審視自己
回顧到第一篇，我希望鐵人賽可以帶給我什麼?
我希望可以透過寫文，逐漸去雕塑自己是什麼樣的人
而透過連續30天發技術文章，這件事其實比想像中還要困難
可能是第一次這麼大量快速的產出文章(又很怕自己給大家看到垃圾內容)，也可能是自己還在成長期，對於很多專業術語與範例
外加上自己龜毛的個性，花了非常多的時間去舉證或思考或審視或排版，進而壓縮自己其他的時間(所以要囤稿xd)
但也很開心，對於這個活動，讓自己培養了寫文章的快樂，也希望能讓文章可以幫助想要參加鐵人賽但不敢行動的人，或者想要學習Design Pattern 想要看更多文章的人
我也很謝謝當初毅然決然要報名這次鐵人賽的自己，在賽期也可以看到其他人撰寫文的強度，每每看到充滿知識性又好理解的文章，我都欽佩不已
我想應該是時間的掌握，對於文章想要表達的內容/邏輯
起初花了超出預期的時間去撰寫，一方面要能了解這個設計模式想要解決的問題，一方面要思考該如何用簡單的方式讓閱讀的人可以快速理解
又期望能在賽期所有的文章具有正確邏輯又有連貫性，有種自己拿刀把自己逼去懸崖邊的感覺xd
提前寫好了一篇文章，但在發布日時又會再重新 review 一次，有時候也會想到前幾天的文章有哪些還沒補充
又會跑回去補充，或者我覺得可以寫更好，又回去修改，這樣一來一往的時間，不自覺就會消耗很多
應該意識到一件事，就是寫文章永遠都會有更好的寫作方式，我要做的應該不是去反覆修改以前寫過的文章
因為當下所寫的內容，就是當前的自己「可以」產出的內容，而是要思考，如何在下篇文章，可以寫到更好，表達得更精確
一定是「好好規劃」，好好規劃30天的內容，好好規劃你想要表達的是什麼，想要傳達什麼理念
如何可以完整的說明一個故事，如何讓看你文章的人，可以產生興趣繼續看下去(胡立大在撰寫文章的技術非常優秀，也有說明他是如何完成一篇文章的？)
但也不希望讓「好好規劃」這件事情，勸退了許多想要參加鐵人賽的朋友
再套一次六角學院校長的名言:「你不用一開始就很厲害，但要開始才有辦法變厲害」
謝謝許多大神先前撰寫許多關於設計模式的文章，讓我在撰寫並查找資料時，可以節省很多理解時間(如果沒有他們，我絕對花更多時間)
也謝謝當初第一個願意按文章 LIKE 的人，真的讓我產生了非常大的動力繼續下去
iThome鐵人賽
看影片追技術